1. Field of the Invention
The invention concerns programming generally and is more specifically directed to techniques for defining a context in which code that is invoked in response to an asynchronous event is executed.
2. Description of the Prior Art
When a computer executes a program, it uses data and code stored in the computer's memory system. When writing a program, a programmer uses names to specify the code and the data. When the program is executed on the computer, the execution of the program provides a context for the names. What the names mean in a given execution depends on the context for that execution. In the prior art, the context for a given part of a program has been defined by means of declarations for names of variables and procedures and functions and of invocations of procedures and functions. The following pseudo-code fragment, which shows parts of two procedures, a and b provides an example of such context definition:
______________________________________ int static.sub.-- 1 global . . . main a int a.sub.-- auto.sub.-- 1, a.sub.-- auto.sub.-- 2 . . . b(a.sub.-- auto.sub.-- 1,a.sub.-- auto.sub.-- 2) . . . int b ( int form.sub.-- 1, form.sub.-- 2 ) int b.sub.-- auto . . . static.sub.-- 1 = form.sub.-- 1 + form.sub.-- 2 + b.sub.-- auto . . . ______________________________________
There are six names of interest in the above fragment: static.sub.-- 1, a.sub.-- auto.sub.-- 1, a.sub.-- auto.sub.-- 2, form.sub.-- 1, form.sub.-- 2, and b.sub.-- auto. static.sub.-- 1 is the name of a global static variable. The name of the variable is known everywhere in the program containing the functions a and b. static.sub.-- 1 further represents only a single location in the memory of the computer upon which the program is executing. Thus, static.sub.-- 1 always represents the current value of that location. a.sub.-- auto.sub.-- 1, a.sub.-- auto.sub.-- 2, and b.sub.-- auto are names of automatic variables. The name of each of these variables is known only within the function where it is declared and each name further represents a given location in memory only during a given execution of the function in which the variable is declared. Consequently, a change in the value of one of these variables during one execution of the function has no effect whatever on its value during a different execution.
form.sub.-- 1 and form.sub.-- 2 are names of formal arguments. These names are known only within the function where they are declared. In that function, they represent values which the function receives as actual arguments when it is executed. For example, in the code fragment above, the function b is invoked as follows: EQU b(a.sub.-- auto.sub.-- 1,a.sub.-- auto.sub.-- 2)
In this invocation, a.sub.-- auto.sub.-- 1 and a.sub.-- auto.sub.-- 2 are actual arguments. When the invocation is executed, the function b is executed, and during that execution, form.sub.-- 1 represents the value of a.sub.-- auto.sub.-- 1 and form.sub.-- 2 represents the value of a.sub.-- auto.sub.-- 2.
The context of a given execution of the function b is thus the global static variable static.sub.-- 1, the values of the actual arguments a.sub.-- auto.sub.-- 1 and a.sub.-- auto.sub.-- 2 (that is to say, the values of these automatic variables at the time of execution), and the automatic variable b.sub.-- auto.
FIG. 1 shows a standard way of implementing a context 101 in the memory of a computer system. In most computer systems, programs are executed by processes, and each process has a process address space, that is, each process appears to have a memory which is separate from that of any other process running in the computer system. One part 103 of the process address space contains storage for static variables, including static.sub.-- 1; another part contains storage for the process's stack 109. There is an area on the stack for each execution of a function in the program which has not yet terminated. This area, which is called a frame 115, contains storage for the actual arguments used in an invocation and the automatic variables created in the invocation. Stack 109 in FIG. 1 is shown at a point where the function a has just invoked the function b. Only the top two frames, 111 and 115, are shown. Frame pointer (FP) 113 marks the beginning of the top frame 115. In frame 111 only the storage for a 's two automatic variables is shown. In frame 115, there is storage 121 and 123 for the values of a.sub.-- auto.sub.-- 1 and a.sub.-- auto.sub.-- 2 at the time of the invocation of b, and storage for b 's automatic variable b.sub.-- auto 125. The order of a.sub.-- auto.sub.-- 1.sub.-- val 121 and a.sub.-- auto.sub.-- 2.sub.-- val 123 in frame 115 is determined by the order of the actual arguments in the invocation of function b.
As the foregoing example has made clear, specification of a context for code is straightforward in situations where there is a direct relationship between the code being invoked and the code containing the invocation. More and more frequently, however, there is no such direct relationship. One example of a programming style in which there is no direct relationship is a style called callback programming. FIG. 2 shows a system 201 in which callback programming is employed. Such systems are typically used to write programs for interactive environments such as graphical user interfaces. In system 201, a hardware device (in this case, a mouse 203) produces a signal 204 which is received by a system-level event handler 205, which is a standard part of system 201. The signal may be produced when the user moves the mouse and thereby moves a pointer in a display or when the user depresses or releases a button on the mouse. System-level event handler 205 responds to signal 204 by providing callback information 211 and then invoking application-level callback code 213 using callback information 211 as actual arguments in the invocation, as indicated by arrow 209.
In some graphical user interface environments, windows in a display are represented by objects termed "widgets", and when system-level event handler 205 responds to signal 204, it determines from the location of the pointer in the display what window in the display the pointer is in and accordingly what widget represents the window. In such an environment, callback information 211 contains at least a pointer to the widget and a value indicating the signal 204 which caused the callback, and callback code 213 typically responds to the callback by setting values in the widget as required to deal with the signal.
In systems like system 201, the system-level handler 205 is developed by systems programmers and provided to applications programmers, who then write the application-level callback code 213 required for their particular application. As far as the applications programmers are concerned, system-level event handler 205 is a "black box", and of course the systems programmers who developed event handler 205 can have no idea whatever of the specific callback code 213 which will be written by the applications programmers. Because this is the case, system 201 must include a mechanism which permits applications programmers to add call back code 213 to system 201 without changing handler 205.
The mechanism for doing this is callback code table 207 and callback information 211. The form and contents of callback information 211 and callback code table 207 are both completely defined for system 201. The applications programmer must understand the contents of callback information 211 when he or she writes callback code 213, and when callback code 213 is finished, the applications programmer must add an entry for callback code 213 to table 207. In the graphical user interface environment, the entry specifies at least the widget for which the function handles signals and the kinds of signals the function deals with. One simple way of handling callback information 211 is to push it onto the stack prior to invoking callback code 213. The callback information thus occupies the location in the frame for the callback code which would be normally occupied by the actual arguments, and the application programmer need only define formal arguments in the callback code in accordance with the contents and arrangement of callback information 211.
While prior-art systems using the callback programming style are effective, programmers using them have missed the clear specification of the context provided by standard programming languages. The chief source of difficulty has been the lack of any way of specifying actual arguments in callback programming. One consequence of this lack has been frequent mistakes in relating the formal arguments of the callback code to the format of callback information 211; another has been that the callback code and the installation of the code into the system are at different locations, leading to increased difficulty in understanding the code for the application. It is an object of the present invention to overcome these drawbacks and thereby to make the callback programming style even more useful than it already is.